In today's converged telecommunications environment, a telephone call may originate in a modern IP network and terminate in or pass through a circuit-based switched network. A network such as a Public Switched Telephone Network (PSTN) using a Signaling System 7 (SS7) protocol may be used to implement traditional switch based communications networks for setting up and tearing down calls. Session Initiation Protocol (SIP) is a signaling protocol for the more modern IP based IMS networks as opposed to the substantial legacy base of the traditional circuit-switch based SS7 networks. SIP defines call-setup and signaling. These features permit the familiar telephone-like operations of dialing a number, causing a phone to ring, and hearing ring back tones or a busy signal.
A Transaction Capabilities Application Part (TCAP) gateway may provide on one end an interface in a service-provider's legacy PSTN network managed through the SS7 signaling protocol and on the other end an interface to other external non TCAP systems. A service using an asynchronous communication interface from a standards based Java Specification Request (JSR) 116 SIP Servlet specification application server to a PSTN over a SS7 protocol for instance, must initiate a communication session over the TCAP server. Additionally, an application server may manage Servlets for multiple communication sessions so as to enable multiple users to place calls on the PSTN concurrently.
Often, both modern network elements and legacy communication systems must communicate in a service provider's network. These hybrid systems are also called upon for new applications, such as converged SIP and HTTP applications, other than those for which they were designed. When legacy systems are used to operate with these new applications, the interface between the legacy system and the more modern system may fail.
When connecting an application such as the open standard JSR116 application with a TCAP interface using asynchronous web services, the TCAP interface may respond immediately to each web service request from the application server with an acknowledgment that the request was received. This allows call processing to continue without waiting for the actual web services response which the TCAP interface sends later in a new web service request that it initiates to the application server.
However, one problem encountered above is that application servers cannot correlate the asynchronous web service request from the TCAP interface to a particular SIP call or Java Specification Request (JSR) 116 application session that initiates the dialogue. The JSR 116 application sends the original request to the TCAP interface but the application server does not have a means of correlating the asynchronous web service request from the TCAP interface to the application session that initiated the original request.
Implementing the application server on a business process engine like the WebSphere™ Process Server (WPS) fails to bridge the legacy SS7 network to the SIP as WPS does not have support for SIP. Also a synchronous design of the web services cannot be deployed in a service provider's network as applications must process incoming asynchronous SIP messages without being blocked on by a web service call.